【レポート】初心者でもできた！CloudEndure を利用したPLMシステム群のAWS の移行 #CUS-38 #AWSSummit

こんにちは！コンサル部のinomaso(@inomasosan)です。

AWS Summit Online Japan 2021が、2021年5月11日(火)、12日(水)で開催中されております。

本記事は2021年5月11日(火)に行われた「初心者でもできた！CloudEndure を利用したPLMシステム群のAWS の移行」のセッションレポートとなります。

セッション概要

"内作でゼロから初めたAWS移行で運用コストを1/5にしたプロジェクトを事例として紹介します"
クラウドを利用したことのないチームが初めて、オンプレミスからアマゾン ウェブ サービス（AWS）へのサービス移行を行ったときの経験を事例紹介します。AWS初心者チームが、プロジェクト発足から4か月で無事に26システムの移行を完了させることが出来た事例で、これからAWS移行をやってみようと思う人へ参考になればと思います。

登壇者

日立Astemo株式会社 情報システム統括本部 担当本部長 里山 元章 氏

セッションレポート

1. セッション対象者

• 自社システムをAWSへ移行したい
• AWSへの移行について興味がある方
• 技術的にもAWS初心者

2. 移行対象システム

• 移行対象
  • 製品ライフサイクル管理システム
  • 設計手配システム、図面管理システムなど設計を支援する複数から構成されるシステム
• 移行理由
  • 2020年8月で　ハードウェアの保守期間が終了
  • 移行対象システムは、ハードウェア・ソフトウェア・データセンタ・運用保守を、SIベンダーからフルマネージドサービスとして提供を受けていたが、AWSへの移行を決断

3. 開発方針

• 時間やスキル等に課題があったので、移行・構築をアウトソースすることも検討した
• アウトソースする場合、IT部門はユーザとベンダー間の発注・事務作業が中心となってしまう
• クラウドシフトを進めるには社内にCoEを育成する必要があるため、構築を自分たちで行いノウハウを残すことにした

4. AWSにおける設計・構築の学習

• AWS Professional Services活用
  • 設計・構築技術を教えて貰いながら、自分たちで実際に検証しながら進めた
  • 自社の技術力の向上が成功の鍵の一つだったので、SIに丸投げだと上手くいかなかったかもしれない

5. 移行全体の流れ

移行全体のステップは以下の通り。

• AWSトレーニングで知識・技術を理解
• 移行に必要な現行環境の情報収集・分析
• システムの設定・構築
• データ移行と監視機能等の追加

AWSを触ったことがないメンバーがほとんどだったので、トレーニングを徹底した。
トレーニングはIT部門だけでなく、ユーザ部門にも参加して貰い、リテラシ全体の向上を図った。

6. 移行対象

• サーバ
  • 物理サーバ：14台
  • Oracle DBアプライアンス：4台
• ストレージ
  • 約8TB
• OS
  • Windows 2012R2 std(本番：66、開発：29)
  • Windows 2016 std(本番：1)

7. データベース移行先

データベース移行は可能な限り RDS for Oracleへリプラットフォームとした。

• 約8割はRDS for Oracleへリプラットフォーム
• 残り2割はEC2へリホスト

8. 情報収集ステップでの課題と対策

主に以下３つの対応に時間がかかった。

• パッケージソフトによってはAWS上で動作保証が明記されていなかったり、ライセンス価格や契約変更が必要となった
• 日立グループの社内ネットワークとインターネットはセキュリティ対策が厳しいため、検討と対策に時間がかかった
• クラウド移行できないものは、自社サーバールームへ引越し

9. 移行ツール選定

• アプリケーションのストレージデータ移行は、ライセンス費用が無料で、最も簡単に移行できるCloudEndureを採用
• データベースは、備え付けのツールでエクスポート・インポートにてデータ移行

10. データ移行期間

実データ移行は23日間。

• データ転送に必要な日数は、CloudEndureで算出される概算転送時間と実際の転送性能を分析して見積もり
• 26システムで8TBほどあるデータは、４つのカテゴリに分類し並行に転送で1ヶ月ほどで移行完了できる見通しとなった

11. システム切り替え時のトラブル

システム切り替えで、データの最終同期や接続先IPアドレス等の変更を2回に分けて実施。

• 1回目で性能問題が発生したが、原因の１つがEC2のメモリ不足だったのでスケールアップで解決
• 原因のもう一つは、ネットワークで特定通信がブロックされリトライが発生したものだったので、2回目の実施前に通信テストの見直しを実施

12. プロジェクト結果

• 4ヶ月で、AWSに26システムを移行
• オンプレミス環境はリソースに余裕を持たせるためオーバスペックだったので、運用コストを大幅に下げることができた

まとめ

安易にアウトソースせず、AWS Professional Servicesを活用し自社で移行対応したことにより、スキル向上やIT部門の信頼度が高まったとのことだったので、とても素晴らしいと感じました。

クラウドの場合、移行完了後も継続的な改善が必要となるため、お客様が自走できるようになった良い事例の一つかと思います。

本件は、AWS Leaders' Voiceでも記事になっておりますので、是非こちらもご参照ください。

この記事が、どなたかのお役に立てば幸いです。それでは！